VII.IG實戰

28 測試驗證，優化建議(如何偷Input欄位，減少所需負擔)

今天有兩個部分，前段是把轉換好的內容拿去驗證器測試，後段是一些筆者在處理簡化欄位的手段，

無論採用什麼樣的方法，等轉換完成後，以TWPAS來說，可以在IG網頁的最右欄"驗證教學"中看使用方法

https://nhicore.nhi.gov.tw/pas/validate.html

至於建置具有TWPAS驗證能力的FHIR Server，請見

https://hackmd.io/@chinlinblog/HJl4gBFLgx

一個正常的驗證成功結果，至少要0 errors，而warnings與informations(notes)則不在導致失敗的範圍內，

筆者並不推薦使用validator_cli.jar，因為官方驗證器在驗證一個IG之前，會先將所有與這個IG相關的IG或package等資源全數引用進來，

就如同前面提到的，動輒數分鐘的驗證實在是沒有效率，

而DICOM實驗室版本的驗證器，底層是Inferno Validator，在驗證效率跟穩定度來說都比官方驗證器好，

總之，當讀者上傳驗證結果後看到最後的結果是Success，這代表至少這份FHIR文件在格式與IG限制上是沒有問題的，

但不代表臨床上會沒有問題，這一點需要專業醫師評估或是我明天會談到的CQL等判斷語言。

由於TWPAS這個實作指引目前是只開放醫事機構端申請的，一般人在最後端實用上會沒辦法將資料上傳給官方，

今天會舉這個IG當例子的原因是這是官方第一份正式開始實用的IG，以使用的角度來說很值得學習整個FHIR在台灣應用的過程，

以筆者個人的角度來看，未來FHIR在台灣的實用場景會越來越多，其中也包含了非官方的資料交換，屆時如醫療資料申請、保險給付等

如果能夠有轉換實作的能力，就可以解決很多在如何做出這個資料格式的難點，

其實FUME只在FHIR的整套流程中佔非常少的部分，畢竟說白了這套工具就是提供來生出FHIR文件的，

但FHIR本身還包含了應用端開發，IG發布與制定指引，資料安全與定義等，

不可否認的是，解決轉換之後才能往下走，

有讀者會問了，其實用各種語言進行Hardcoding也是可以的，也有提供SDK可以用，

筆者的想法是，只要能達成目的的方法，都是好方法。

會在這篇系列文介紹FUME也只是單純筆者研究了這個工具，希望讓更多人能夠克服轉換的流程，拋磚引玉。

再來我想講的是簡化欄位的思路分享，

前面幾篇在寫TWPAS的FUME Mapping的時候，筆者其實不太著墨輸入端的內容，

因為這部分是希望讀者可以自行定義拿來轉換的欄位名稱，

這部分筆者認為的指導原則是，

FUME的Mapping應該優先處理IG的必填欄位，再來是臨床資料所需的欄位，最後才是非必填而無關緊要的欄位

而輸入端的思維稍微不一樣，從筆者提供的輸入範例可以看到，輸入端其實是可以分拆成

1. FHIR格式的必要欄位，如status, resource id, REST Method, reference與sequence等

2. IG要求的必填欄位，通常與臨床上的必要資料有高度正相關

3. IG所列的選填欄位，可做補充或是完善資料用途

輸入端的要求反而是 2 > 3 > 1，
盡可能地讓使用者只填入他們所需要填入的臨床資料，
而不需要讓他們去分心填答Resource的ID，該用哪個CodeSystem等技術性的問題

簡化的程度當然還是要拿捏，除非資料的輸入格式被強制定義下來了，

這也是希望讀者要能讀懂IG，才能比較妥適的設計出簡化又不失靈活的欄位。

復盤一下前面兩天的TWPAS內容，筆者大概做了幾件事情

1. 簡化掉claim的supportingInfo, procedure等欄位的內容，流水號等

2. 用$wrap()自定義function來把Resource ID包裝成xhtml的內容

3. 自動判斷value[x]在Observation內的型態別，自動採用適用的value[x]

4. 建立小的CodeSystem內容為物件或擷取CodeSystem的編碼特徵，讓選用的system自行依照輸入的Code來改變

5. 部分未填入或不好填入的必填資料，先有一個基礎內容可以return，如MIME Type

要再簡化下去當然也可以，所有的Resource ID也可以透過身分證字號或病歷號+ResourceType來合併，

但就最終還是回到需求本身要怎麼處理。